<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.66">
 <TITLE>libuser 0.52.2: System Administration</TITLE>
 <LINK HREF="libuser-1.html" REL=previous>
 <LINK HREF="libuser.html#toc2" REL=contents>
</HEAD>
<BODY>
Next
<A HREF="libuser-1.html">Previous</A>
<A HREF="libuser.html#toc2">Contents</A>
<HR>
<H2><A NAME="s2">2.</A> <A HREF="libuser.html#toc2">System Administration</A></H2>

<P>This section describes libuser's configuration file and bundled
applications which may be of use to system administrators.</P>

<H2><A NAME="ss2.1">2.1</A> <A HREF="libuser.html#toc2.1">Configuration</A>
</H2>

<P>The libuser configuration file is named <B>libuser.conf</B> and
usually lives in <B>/etc</B>.  Its format is the common format used
by numerous other programs.  Sections are marked by the section name
enclosed in square brackets (<B>[section]</B>), and configuration
directives within these sections are of the form <B>key = value</B>.</P>

<P>The <B>defaults</B>, <B>userdefaults</B>, and <B>groupdefaults</B>
sections are used by the library itself.  The <B>defaults</B> section
specifies the directory where modules can be found (<B>moduledir</B>) and
lists the modules to be consulted when looking up user information.</P>

<P>There are two lists of modules because <B>libuser</B> separates an
account's authentication information from other information.  This is done
to allow different information stores to be used for these functions, and
because some information stores can only hold authentication data (for
example, shadow).</P>

<P>For the <B>info_modules</B> and <B>auth_modules</B> lists, order
is only important for account creation -- the library will attempt to
create a data entry for the user in each of the modules until one of them
succeeds (so if you prefer new accounts to be created in your LDAP
directory, then you'd make sure &#34;ldap&#34; was listed <I>before</I>
&#34;files&#34;).  For looking up account information, the order determines
precedence because the library stops searching after a module returns success
(so again, you'd want &#34;ldap&#34; listed before &#34;files&#34;).
Account modifications and deletions go straight to the information store which
is known to hold the user's information.</P>

<H2><A NAME="ss2.2">2.2</A> <A HREF="libuser.html#toc2.2">Modules</A>
</H2>

<P>Specific modules implement access to specific information stores.  The
modules included in the source distribution are the <B>files</B> and
<B>shadow</B> modules.  Modules can supply and manipulate either (or both)
of two distinct types of data about a user: generic user information (the
UID, home directory, etc.), and authentication-related information.</P>

<H3>files</H3>

<P>The files module implements both information and authentication data
stores using the standard <B>passwd</B> and <B>group</B> files.</P>

<P>This module uses the <B>files</B> section of the configuration file
to store configuration data.  It presently recognizes these flags:</P>
<P>
<UL>
<LI>directory - the directory the <B>passwd</B> and <B>group</B> files
are to be stored in</LI>
</UL>
</P>

<H3>shadow</H3>

<P>The shadow module implements only an authentication data store using
the <B>shadow</B> and the <B>gshadow</B> files.  While the format of
these files (and even the existence of the <B>gshadow</B> file) varies
between OSs, this module supports the same file formats used by the shadow
password suite.</P>

<P>This module uses the <B>shadow</B> section of the configuration file
to store configuration data.  It presently recognizes these flags:</P>
<P>
<UL>
<LI>directory - the directory the <B>shadow</B> and <B>gshadow</B>
files are to be stored in.</LI>
</UL>
</P>

<H3>ldap</H3>

<P>The ldap module implements both information and authentication data stores
using an LDAP directory and a schema which (should) conform to RFC2307.  The
module expects the client and server to support access using LDAPv3 with TLS;
TLS is not required if the server is specified by URI.</P>

<P>This module uses the <B>ldap</B> section of the configuration file
to store configuration data.  It presently recognizes these flags:</P>
<P>
<UL>
<LI>server - the hostname or URI of the LDAP server</LI>
<LI>basedn - the distinguished name which is the root of your tree</LI>
<LI>user - the user name with which to perform SASL binds</LI>
<LI>authuser - the authorization user name with which to perform SASL binds</LI>
<LI>binddn - the distinguished name to connect as for administrative access</LI>
<LI>userBranch - the distinguished name (relative to the basedn) under which
user account data is kept</LI>
<LI>groupBranch - the distinguished name (relative to the basedn) under which
group account data is kept</LI>
</UL>
</P>

<H2><A NAME="ss2.3">2.3</A> <A HREF="libuser.html#toc2.3">Applications</A>
</H2>

<P>Sample testbed applications which mimic the behavior of certain parts
of the shadow password suite are included in the libuser distribution.
To allow them to be used alongside existing utilities, their names have
been prefixed with the letter 'l'.</P>

<P>As of this writing (version 0.7), this list of tools includes
workalikes for <B>useradd</B>, <B>usermod</B>, <B>userdel</B>,
<B>groupadd</B>, <B>groupmod</B>, <B>groupdel</B>, and <B>chage</B>.
It should be noted that none of these tools provide a means for modifying
the defaults they use, and no functions for creating, populating, moving, or
deleting user home directories are implemented.</P>

<HR>
Next
<A HREF="libuser-1.html">Previous</A>
<A HREF="libuser.html#toc2">Contents</A>
</BODY>
</HTML>
